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ABSTRACT 


Information  Security  is  traditionally  treated  in  three  main  categories:  Con¬ 
fidentiality,  Integrity ,  and  Availability.  While  much  work  has  been  done  on 
modelling  Confidentiality  and  Availability,  aspects  involving  comprehensive 
modelling  and  quality  of  data  integrity  in  complex  systems  appear  to  be,  on  a 
relative  scale,  much  less  well  understood  and  implemented.  Further,  most  work 
on  Integrity  and  resultant  implementations  seems  to  have  focussed  more  on  a 
matters  related  to  source  authentication  and  transmission  assurance.  However, 
the  quality  of  data  aspect  is  becoming  more  critical  for  attention,  given  the 
increasing  levels  of  automation  of  information  fusion  and  data  transformation 
in  a  globalised  Cyberspace. 

In  this  paper,  we  survey  the  existing  integrity  models  and  identify  short¬ 
comings  of  these  with  regard  to  a  general  integrity  framework  encompassing  the 
quality  of  data  aspect.  We  then  propose  and  formally  model  a  new  framework, 
illustrating  the  approach  with  reference  to  use  cases  built  around  the  Secure 
Information  ATM  (SIATM)  -  a  highly  accreditable  security  system  currently 
under  development. 
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A  Formal  Integrity  Framework  with  Application  to  a  Secure 

Information  ATM  (SIATM) 

Executive  Summary 

Information  Security  is  traditionally  treated  in  three  main  categories:  Confidentiality,  In¬ 
tegrity,  and  Availability.  While  much  work  has  been  done  on  modelling  Confidentiality 
and  Availability,  aspects  involving  comprehensive  modelling  and  quality  of  data  integrity 
in  complex  systems  appear  to  be,  on  a  relative  scale,  much  less  well  understood  and  im¬ 
plemented.  Further,  most  work  on  Integrity  and  resultant  implementations  seems  to  have 
focussed  more  on  a  matters  related  to  source  authentication  and  transmission  assurance. 
However,  the  quality  of  data  aspect  is  becoming  more  critical  for  attention,  given  the  in¬ 
creasing  levels  of  automation  of  information  fusion  and  data  transformation  in  a  globalised 
Cyberspace.  Without  a  comprehensive  ability  to  measure  integrity  systematically,  consis¬ 
tently,  and  within  its  correct  context,  military  systems  may  struggle  to  take  full  advantage 
of  emerging  trends. 

Two  primary  and  distinct  models  have  previously  been  proposed  as  a  foundation  for 
systems  to  manage  and  reason  about  data  quality  integrity  as  a  part  of  the  information 
security  equation:  the  Biba  Integrity  Model  and  the  Clark- Wilson  Integrity  Model.  In 
this  paper,  we  first  review  the  Biba  and  Clark-Wilson  integrity  models,  highlighting  the 
key  attributes,  limitations  and  later  extensions  to  the  models.  The  balance  of  the  paper 
identifies  research  challenges  in  addressing  integrity  and,  critically,  proposes  a  new  model 
that  captures  and  supports  a  broader  range  of  integrity  dimensions.  Finally,  we  briefly 
discuss  a  use  case  for  the  model  involving  an  actual  implementation  of  a  security  device 
(Secure  Information  ATM  or  SIATM)  which  is  to  undergo  test  deployment  in  several 
military  systems. 
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1  Introduction 


Information  Security  is  traditionally  treated  in  three  main  categories:  Confidentiality,  In¬ 
tegrity,  and  Availability.  While  much  work  has  been  done  on  modelling  Confidentiality  and 
Availability  (with  a  publicised  focus  on  Denial  of  Service),  aspects  involving  comprehen¬ 
sive  modelling  and  quality  of  data  integrity  in  complex  systems  which  are  integrated  into 
the  overall  security  equation  appear  to  be,  on  a  relative  scale,  much  less  well  understood 
or  implemented.  Further,  most  work  on  Integrity  and  resultant  implementations  seems  to 
have  focussed  more  on  matters  related  to  source  authentication  and  transmission  assur¬ 
ance,  for  which  there  is  a  significant  body  of  knowledge  (see  e.g.  [Menezes,  van  Oorschot 
&  Vanstone  2001]  or  [Bishop  2003]).  However,  given  the  increasing  levels  of  automation 
of  information  fusion  and  data  transformation  in  a  globalised  Cyberspace,  the  quality  of 
data  aspect  is  becoming  more  critical  for  attention.  Automated  data  fusion  using  mul¬ 
tiple  sources  under  multiple  jurisdictions  with  differing  systems  assurance  and  differing 
algorithmic  implementations,  all  in  a  distributed  environment,  is  expected  to  become  the 
norm.  Given  this  trend,  the  effect  of  a  contaminated  (or  even  more  subtly  out  of  context) 
data  item  or  stream  being  fused  or  transformed  into  an  output  stream  involving  auto¬ 
mated  intermediate  processing  stages,  and  where  one  or  more  transformation  processes 
themselves  may  have  differing  correctness,  context  and  ownership/control/policy  imple¬ 
mentations  (and  where  some  critical  decision  is  taken  on  the  viewed  output),  is  not  at  all 
well  understood.  Furthermore,  the  output  may  itself  be  viewed  by  some  automated  process 
which  undertakes  a  course  of  action.  Even  if  the  viewing  process  itself  is  well  implemented, 
a  contaminated  intermediate  processing  stage,  or  data  stream  which  underwent  fusion  and 
transformation,  could  result  in  an  incorrect  course  of  action. 

Without  a  comprehensive  ability  to  measure  integrity  systematically,  consistently,  and 
within  its  correct  context,  military  systems  may  struggle  to  take  full  advantage  of  emerging 
trends  such  as  heterogeneous  Cloud  based  systems  (note  that  there  are  a  still  a  number 
of  challenges  in  the  Confidentiality  and  Availability  areas  yet  to  be  solved  as  well  as  the 
Integrity  aspects).  This  limited  capability  causes  significantly  greater  incurred  expense  in 
the  use  of  many  separate  single  purpose  systems,  which  in  themselves  may  introduce  other 
errors  or  low  integrity  issues.  These  issues  may  include,  for  example,  multiple  human  in 
the  loop  failure  modes. 

Some  may  argue  that  work  in  Safety  Critical  areas  focusses  primarily  on  integrity  and 
this  in  itself  is  true.  However,  it  tends  to  deal  with  the  correctness  of  function  in  a  single 
context  for  a  system,  and  does  not  focus  on  multiple  contexts  of  data  and  processing 
modules,  and  trends  to  promoting  a  view  that  a  system  either  has  a  sufficient  level  of 
integrity  or  not  rather  than  one  which  presumes  multiple  contexts  which  may  change 
dynamically. 

Two  primary  and  distinct  models  have  previously  been  proposed  as  a  foundation  for 
systems  to  manage  and  reason  about  data  quality  integrity  as  a  part  of  the  information 
security  equation:  the  Biba  Integrity  Model  [Biba  1977]  and  the  Clark-Wilson  Integrity 
Model  [Clark  &  Wilson  1987].  In  this  paper,  we  first  review  the  Biba  and  Clark-Wilson 
integrity  models,  highlighting  the  key  attributes,  limitations  and  later  extensions  to  the 
models.  The  balance  of  the  paper  identifies  research  challenges  in  addressing  integrity  and 
proposes  a  new  model  that  captures  and  supports  a  broader  range  of  integrity  dimensions. 
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Finally,  we  briefly  discuss  a  use  case  for  the  model  involving  an  actual  implementation  of  a 
security  device  (Secure  Information  ATM  or  SIATM)  which  is  to  undergo  test  deployment 
in  several  military  systems. 


1.1  Biba  Integrity  Model 

The  Biba  Integrity  Model  [Biba  1977]  stated  that  the  information  protection  issue  has 
two  parts:  the  first  part  addresses  the  proper  dissemination  of  information,  while  the 
second  part  relates  to  the  validity  of  information,  or  integrity.  Biba  went  on  to  propose 
a  model  that  focussed  on  providing  a  measure  of  integrity  for  subjects  and  objects,  and 
the  prevention  of  the  invisible  introduction  of  data  with  lesser  integrity  within  a  defined 
system.  Biba  defined  a  mathematical  model  to  describe  allowable  read/write  interactions 
between  pairs  of  subjects  and  objects,  based  on  a  set  of  ordered  integrity  levels.  Using  the 
model,  he  presented  three  integrity  policies,  described  below. 

The  strict  integrity  policy  is  the  dual  of  the  Bell-LaPadula  confidentiality  model  [Bell 
Sz  LaPadula  1973].  Given  the  function,  Ivl,  which  provides  the  integrity  level  of  a  subject 
or  object,  for  any  subject  s  (and  si  and  s2),  and  object  o,  the  strict  integrity  policy  is  as 
follows. 

1.  s  can  read  o  if  and  only  if  lvl(s)  <  lvl(o) 

2.  s  can  write  to  o  if  and  only  if  lvl(o)  <  lvl(s) 

3.  si  can  execute  s2  if  and  only  if  lvl(s 2)  <  Ivl(sl) 

In  summary,  the  policy  allows  data  to  flow  from  high  integrity  levels  to  low  integrity 
levels  only  (see  Figure  1). 


Figure  1:  Data  flows  towards  low  integrity. 

When  this  policy  is  implemented  in  conjunction  with  a  confidentiality  policy  (such  as 
the  Bell  LaPadula  model)  data  flow  is  even  more  restrictive.  If  Biba  and  Bell  LaPadula 
levels  correspond  such  that  integrity  levels  increase  as  confidentiality  levels  increase,  in¬ 
formation  remains  at  level.  However,  in  reality,  each  integrity  level  may  contain  data  of 
different  confidentiality  levels.  In  this  case,  the  model  allows  information  to  flow  between 
levels;  however,  it  flows  to  lower  integrity  levels  and  to  higher  confidentiality  levels  (see 
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Figure  2).  Over  time,  the  natural  result,  is  a  system  populated  by  information  that  is 
highly  classified  with  low  integrity. 


Figure  2:  Data  flows  towards  high  classification  and  low  integrity. 

The  low-water  mark  policy  is  similar  to  the  above,  only  it  allows  for  more  interaction 
between  entities  by  enabling  subjects  to  read  objects  with  a  lower  integrity  level.  However, 
once  such  a  read  takes  place,  the  subject’s  integrity  level  becomes  that  of  the  object. 

Like  the  low-water  mark  policy,  the  ring  policy  allows  subjects  to  read  objects  with 
a  lower  integrity  level  but,  in  this  case,  without  the  need  for  subjects  to  be  downgraded. 
After  reading  from  a  lower  level,  the  subject  can  write  to  its  level,  thus  allowing  information 
to  flow  to  a  higher  integrity  level.  However,  the  condition  under  which  this  is  appropriate  is 
not  specified  as  part  of  the  model;  it  is  left  to  the  subject  to  validate  observed  data.  Indeed, 
Biba  introduces  a  capability  policy  to  cater  for  trusted  processes  that  operate  outside  of 
the  policies  allowing  data  integrity  levels  to  be  upgraded. 

Biba  also  introduced  a  discretionary  protection  policy  to  allow  administrators  to  spec¬ 
ify  what  particular  users  can  do  (read/write/execute)  to  particular  objects  via  subjects. 
Again,  this  is  a  “dual”  of  traditional  access  control  lists  in  discretionary  security  policies 
for  confidentiality  maintenance. 

There  have  been  several  applications  and  variations  of  the  Biba  model  ([Hu  &  Feng 
2008];  [Zhang  2009];  [Lunt  et  al.  1990];  [Schell  &  Denning  1986];  [Zun,  Tao  &  Wei- 
hua  2009];  [Tang  &  Qing  2006]),  including  two  that  incorporate  the  Bell-LaPadula  confi¬ 
dentiality  model  ([Zhang,  Yun  &  Zhou  2008];  [Lipner  1982]). 


1.2  Clark- Wilson  Integrity  Model 

[Clark  &  Wilson  1987]  expanded  the  scope  of  integrity  maintenance  when  compared  to  the 
Biba  model  by  including  protection  against  authorised,  but  improper,  modifications  for 
the  purpose  of  preventing  and  detecting  fraud  in  commercial  systems.  The  Clark-Wilson 
model  proposes  two  integrity  levels  based  on  a  distinction  between  constrained  data  items 
(CDIs),  data  that  is  already  part  of  the  system,  and  unconstrained  data  items  (UDIs),  new 
data  that  is  being  introduced  to  the  system. 

Well  formed  transformation  procedures  (TPs)  and  integrity  verification  procedures 
(IVPs)  are  introduced  as  the  means  of  ensuring  a  system  progresses  from  one  valid  state 
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to  another,  based  on  one  or  more  inputs  (see  Figure  3).  Typically,  TPs  operate  on  a  set  of 
CDIs.  However,  certain  certified  processes  may  also  operate  on  UDIs  in  order  to  introduce 
the  data  to  the  system,  thus  labelling  them  as  CDIs. 


Figure  3:  A  well  formed  TP  operating  on  two  CDIs  with  a  combined  output. 

The  model  is  described  by  a  set  of  enforcement  rules  and  certification  rules :  those  that 
state  what  can  be  maintained  by  the  system,  and  those  that  state  what  must  be  done  by 
entities  outside  of  the  system,  respectively. 

Separation  of  duty  and  general  access  control  is  catered  for  by  requirements  to  restrict 
what  TPs  users  can  execute,  and  on  which  particular  CDIs.  Other  security  requirements 
regarding  user  authentication  and  audit  logging  are  also  expressed  within  the  rules. 

Although  the  Clark-Wilson  model  assumes  a  single  high  level  of  integrity  applies  to 
CDIs,  a  model  with  more  explicit  rules  for  managing  system  data  at  multiple  integrity 
levels  (for  instance,  Biba’s  model)  may  be  incorporated  within  it  [Bishop  2003]. 

There  have  been  several  applications  and  variations  of  the  Clark-Wilson  model  ([Hanigk 
2009];  [Ge,  Polack  &  Laleau  2004];  [Qingguang,  Sihan  &  Yeping  2006]),  including  one 
which,  as  [Bishop  2003]  describes,  incorporates  the  Biba  model  as  the  integrity  policy 
used  [Zhou-Yi,  Ye-Ping  &  Hong-Liang  2010]. 


1.3  Limitations  of  the  Models 

The  Clark-Wilson  model  provides  a  general  framework  in  which  data  integrity  can  be 
managed;  however,  it  can  be  interpreted  in  many  ways  and  needs  to  be  coupled  with  a 
model  providing  stricter  guidance  for  practical  data  integrity  management. 

Both  models  describe  the  need  for  human  intervention  and  certified  or  trusted  processes 
to  upgrade  or  establish  data  integrity.  Little  guidance  for  such  processes  is  provided,  thus 
leaving  the  models  inherently  subject  to  integrity  decay. 

Although  the  Clark-Wilson  model  allows  for  processes  to  operate  on  multiple  data 
sources  (unlike  Biba’s  model),  neither  model  considers  how  the  existence  of  multiple 
sources  of  related  data  can  affect  their  assigned  integrity  levels.  For  example,  one  piece 
of  data  may  increase  or  decrease  the  integrity  level  of  another  based  on  whether  the  data 
is  confirmed  or  contradicted,  and  also  on  the  degree  of  independence  of  the  data  sources. 
Furthermore,  the  models  do  not  capture  contextual  information  by  which  independence  is 


4 


UNCLASSIFIED 


UNCLASSIFIED 


DSTO-TR-2726 


inferred.  There  are  numerous  examples  of  where  this  can  be  critical  depending  on  the  mis¬ 
sion  of  the  processing  taking  place  and  the  data  incest  problem  for  sensors.  As  a  particular 
example  consider  the  safety  critical  case  where  a  plane  crashed  due  to  a  faulty  altitude 
sensor  which  provided  the  same  input  into  two  seemingly  separate  and  independent  sys¬ 
tems  (the  pilots  asked  a  tower  for  an  altitude  check  on  hearing  an  alarm,  but  unfortunately 
the  tower  used  the  same  faulty  sensor  as  the  plane  for  its  determination  [Casey  2006]). 

Although  Biba’s  model  aims  to  prevent  potential  corruption  or  decrease  in  assured 
integrity  of  data  by  lower  integrity  subjects,  the  model  assumes  subjects  won’t  corrupt 
data  at  (or  below)  level  deliberately  or  accidentally,  whereas  the  Clark-Wilson  model 
attempts  to  address  this  by  requiring  separation  of  duty.  Here  Clark  and  Wilson  attempt 
integrity  maintenance  but  note  that  the  model  implies  a  single  level  of  integrity  (either 
integrity  is  maintained  or  it  is  not)  thus  negating  opportunities  to  make  decisions  based 
on  the  notion  of  sufficient  integrity  for  the  particular  context  and  circumstances  at  hand 
(these  may  change  under  different  conditions  which  cannot  be  encoded  in  the  TP).  Even  if 
the  Biba  model  is  included  along  with  the  notion  of  separation  of  duty  as  per  [Bishop  2003] , 
the  resultant  model  still  implies  a  single  context  for  a  system  when  making  a  comparative 
assessment  between  entities  thus  placing  enormous  constraints  on  what  would  constitute 
sufficient  integrity. 

Traceability  is  necessary  to  provide  auditing  and  analysis,  including  the  ability  to  make 
decisions  about  data  integrity  based  on  the  history  of  data.  The  Clark-Wilson  model  allows 
for  traceability,  whereas  there  is  no  discussion  in  the  Biba  model. 


1.4  Requirements  and  Challenges  for  a  New  Model 

The  systems  for  which  we  want  to  manage  integrity  involve  data  from  all  manner  of  sources 
and  different  processing  requirements  across  multiple  jurisdictions,  all  with  varying  con¬ 
texts  and  levels  of  integrity.  In  these  systems  we  need  a  way  of  supporting  the  automation 
of  decisions  regarding  the  integrity  of  data  and  processing  as  it  is  sourced,  used  and  main¬ 
tained.  A  quantitative  measure  of  integrity  (Biba  employs  a  simple  quantitative  scheme) 
will  capture  the  notion  of  such  varied  levels  and  enable  an  implemented  system  to  inter¬ 
pret  it  for  decisions  seeking  sufficient  integrity  for  the  context  and  circumstances  of  the 
moment.  In  terms  of  Clark-Wilson,  all  data  in  our  system  will  be  CDIs  tagged  with  an 
associated  measure  of  integrity.  Ideally,  the  measurement  can  be  comparable  across  en¬ 
tities  (for  example,  subjects  and  objects),  while  maintaining  context  and  not  introducing 
out  of  context  comparisons 

We  want  our  model  to  be  able  to  increase  or  decrease  data  integrity  levels  based 
on  multiple  sources  of  data.  In  particular,  we  are  interested  in  what  we  call  integrity 
amplification,  that  is,  when  multiple  sources  of  data  are  combined  to  produce  data  of  a 
higher  integrity  level.  This  can  provide  a  method  to  address  the  inherent  decay  trend  in 
existing  integrity  models  and  assist  to  avoid  the  need  for  system  wide  certified  upgrade 
processes  or  human  intervention.  This  may  be  achieved  by  directly  providing  support 
for  measuring  the  independence  of  data  sources.  To  reason  about  multiple  data  sources 
effectively,  our  model  will  need  to  account  for  the  context  of  the  data.  Data  may  have  a 
high  level  of  integrity  in  one  context  but  a  lower  level  in  another. 
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There  are  many  dimensions  to  context  such  as  data  source,  time  of  creation,  method  of 
instantiation,  and  classification  (to  name  a  few)  which  can  all  contribute  to  the  context  of 
data;  the  number  of  possible  contexts  is  actually  infinite  and  dependent  on  the  particular 
purpose  for  which  processing  is  undertaken.  Our  model  will  need  to  provide  practical 
support  for  these  multiple  dimensions  in  order  to  contribute  to  a  measure  of  integrity 
which  can  be  used  in  the  context  of  the  moment. 

Like  Clark  and  Wilson,  we  want  our  model  to  provide  support  for  traceability.  For 
example,  we  must  be  able  to  identify  when  and  from  where  certain  data  has  been  intro¬ 
duced,  and  when,  how  and  by  whom  operations  have  been  made,  and  whether  operations 
have  been  performed  by  one  individual  or  multiple. 

For  the  reader’s  convenience,  the  following  table  highlights  the  differences  between  the 
two  prominent  existing  models  and  our  desired  model. 


Biba 

Clark-Wilson 

Desired  Model 

Quantitative  measure 

Y 

N 

Y 

Comparable  across  entities 

Y 

N 

Y 

Automated  integrity  amplification/ 
attenuation 

N 

N 

Y 

Data  source  independence 

N 

N 

Y 

Data  context  sensitivity 

N 

N 

Y 

Traceability 

N 

Y 

Y 

Separation  of  duty 

N 

Y 

Y 

Table  1:  A  comparison  of  existing  models  against  requirements. 


2  Overview  of  Approach 

Our  approach  is  rooted  in  the  observation  that  the  integrity  of  a  Data  Element  is  de¬ 
pendent  on  a  multi-dimensional  Context  Vector.  In  an  appropriate  coordinatization  of 
the  space  spanned  by  such  Context  Vectors,  each  axis  will  represent  ideally  a  well-defined 
independent  and  atomic  conceptual  context,  e.g.  authentication  or  reputation.  In  our 
model,  the  integrity  of  the  Data  Element  is  derived  from  this  in  a  manner  which  will  be 
described  below. 

In  practise,  the  number  of  context  dimensions  in  our  “universe”  of  systems  is  effec¬ 
tively  infinite.  An  assignment  of  a  meaningful  value  for  all  dimensions  typically  would 
not  make  sense,  and,  naturally,  for  reasons  of  practicality  of  implementation,  we  do  not 
want  to  attach  to  each  Data  Element  an  all-encompassing  vector  which  assigns  a  value  to 
a  component  in  each  of  these  dimensions.  Hence  the  approach  adopted  is  one  of  specify¬ 
ing  a  particular  integrity  model  relevant  to  a  system  or  set  of  systems,  with  that  model 
identifying  the  context  dimensions  of  relevance.  Only  context  values  in  those  dimensions 
are  required  to  be  associated  with  Data  Elements  in  that  model.  In  addition,  as  we  will 
describe,  the  specification  of  a  particular  integrity  model  also  describes  functions  specific 
to  that  model  which  will  update  the  Context  Vector  of  a  Data  Element  in  response  to 
actions  on  that  data,  and  evaluate  integrity  for  that  Data  Element  as  a  function  of  its 
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Context  Vector.  (Issues  to  do  with  the  handling  of  data  aggregation,  e.g.  evaluation  of 
integrity  across  files,  will  be  briefly  touched  on  later.  For  now,  the  focus  is  on  the  simple 
atomic  data  constituents  within  the  model.) 

We  introduce  the  concept  of  a  Model  List  as  an  ordered  collection  of  models.  Specific 
models  in  a  Model  List  are  to  be  referenced  via  a  Model  Index. 


To  each  Data  Element  we  attach  an  Integrity  Label. 


Data 


Integrity  Label 


where  an  Integrity  Label  comprises 


•  a  Model  Index, 

•  an  Initial  Integrity  value,  and 

•  a  Context  Vector. 

The  Integrity  Label  is  securely  bound  to  the  Data  Element,  though  the  mechanism  of 
this  binding  is  not  relevant  at  this  level  of  abstraction. 

In  turn,  a  Context  Vector  comprises  an  ordered  set  of  one  or  more  scalars,  where  each 
scalar  represents  the  value  of  a  context  dimension.  Note  that  the  actual  space  (e.g.  contin¬ 
uous  vs  discrete)  may  be  specified  independently  for  each  model  and  for  each  dimension. 

The  Model  Index  identifies  an  Integrity  Model.  This  comprises 

•  a  list  of  the  context  dimensions  which  are  of  relevance  to  this  model, 

•  a  functional  specification,  contextUpdate ,  of  the  update  of  the  Context  Vector  in 
response  to  an  Event,  and 

•  a  functional  specification,  evaluatelntegrity,  of  the  evaluation  of  the  Integrity  of  the 
Data  Element  from  the  Context  Vector  and  Initial  Integrity. 

The  approach  taken  is  as  follows.  The  Context  Vector  attached  to  a  Data  Element 
is  initialised  appropriately  for  the  selected  Model  Index,  i.e.  it  is  assigned  a  value  for 
each  of  the  Context  Dimensions  identified  in  the  specific  model  as  of  relevance.  Typically, 
this  will  take  place  either  when  the  Data  Element  enters  the  system  (across  some  defined 
boundary)  or  is  created  (special  case  of  entering  the  system).  Subsequently,  each  Event 
which  occurs  within  the  system  and  which  has  an  effect  on  that  Data  Element  will  update 
the  Context  Vector  as  per  the  corresponding  function,  updateContext,  specified  in  the 
specific  model.  At  any  instant,  the  Integrity  of  the  Data  Element  may  be  evaluated  from 
its  current  Context  Vector,  again  using  the  corresponding  function,  evaluatelntegrity ,  from 
the  specific  model. 


2.1  Transition  of  Data  Elements  Between  Models 

The  framework  must  support  transition  of  Data  Elements  between  models,  and  also  facil¬ 
itate  entry  of  fresh  data  into  the  system.  In  this  paper,  we  address  this  problem  via  use 
of  an  Initial  Integrity  value  attached  to  each  Data  Element. 
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When  a  switch  of  Integrity  Model  is  made  {i.e.  by  updating  the  Data  Element’s  Model 
Index),  the  current  Context  Vector  may  be  used  to  evaluate  the  current  integrity  value 
(via  the  evaluatelntegrity  method  of  the  initial  model).  This  value  may  then  be  stored  in 
the  Initial  Integrity  value  of  the  Data  Element  in  the  new  model  and/or  an  initial  Context 
Vector  is  assigned  in  the  new  model  (for  the  new  set  of  relevant  dimensions).  Hence  the 
evaluatelntegrity  method  must  take  into  account  the  Initial  Integrity  value  as  well  as  the 
current  Context  Vector  in  determining  the  current  integrity  of  the  data.  Similarly,  we  also 
include  the  Initial  Integrity  value  as  an  input  to  the  contextUpdate  method,  since  such  a 
dependency  cannot  in  general  be  excluded.  A  formal  representation  of  this  approach  is 
given  in  Appendix  B. 

However,  we  note  here  that  the  authors  regard  this  approach  to  data  transition  as  not 
necessarily  natural  within  the  given  framework.  Further  research  is  planned  to  explore 
other  alternatives.  Other  approaches  than  the  use  of  the  Initial  Integrity  value  above 
might  include  the  following. 

•  The  simplest  approach  is  for  the  Context  Vector  attached  to  each  Data  Element  to 
include  all  of  the  Context  Dimensions  relevant  to  the  set  of  models  through  which  the 
Data  Element  passes.  This,  of  course,  will  typically  be  impractical  in  terms  of  the 
size  of  the  vector  alone.  In  addition,  within  a  given  model,  one  could  not  reasonably 
expect  it  to  actively  maintain,  in  response  to  events,  the  set  of  dimensions  which  it 
does  not  regard  as  relevant;  hence  these  Context  Dimensions  would  be  out  of  date 
when  the  transition  to  the  next  model  is  made. 

•  A  slight  variation  on  the  above  approach  is  to  accumulate  Context  Dimensions  in  the 
Context  Vector  attached  to  the  Data  Element  as  it  passes  through  the  various  models. 
This  mitigates  the  worst  case  approach  above  of  handling  all  Context  Dimensions  at 
all  times.  However,  this  might  lead  to  a  proliferation  of  models,  and,  moreover,  one 
would  be  forced  to  either,  in  a  given  system,  cope  with  a  multitude  of  models  (for 
data  arriving  from  different  external  models),  or  adopt  a  single  superset  model  within 
the  system,  growing  with  every  new  external  model  from  which  data  is  encountered. 

•  In  another  approach,  one  could  introduce  some  mapping  (indexed  by  the  pair  of 
model  indices)  which  takes  the  final  vector  from  one  model  and  maps  it  to  an  initial 
vector  in  the  new  model.  This  is,  in  some  sense,  equivalent  to  the  Initial  Integrity 
value  approach  adopted  currently,  in  that  we  need  to  ensure  that  the  evaluation  of 
the  integrity  in  the  original  model  for  the  final  vector  is  the  same  as  the  evaluation  of 
the  integrity  in  the  new  model  for  the  initial  vector  in  that  model.  However,  it  may  be 
a  more  natural  formulation  for  many  purposes.  One  issue  with  this  approach  though 
would  be  that  the  choice  of  the  initial  vector  in  the  new  model  will  typically  not  be 
unique.  A  (typically  infinite)  set  of  vectors  will  evaluate  to  the  correct  integrity; 
with  not  all  of  these  vectors  necessarily  being  truly  equivalent,  since  this  will  depend 
on  the  specific  details  of  the  models.  The  use  of  an  Initial  Integrity  value  instead 
avoids  having  to  make  what  might  be  a  semi-arbitrary  choice  in  the  mapping. 

•  Finally,  an  alternative  approach  is  to  introduce  an  additional  integrity  model  (in  our 
indexed  list)  which  is  the  fusion  (in  some  sense  to  be  defined)  of  the  two  models 
involved  in  the  transition,  and  which  acts  as  a  staging  post  for  the  transformation 
of  the  Data  Element  and  its  metadata. 
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3  Formalised  Generic  Integrity  Model 

In  this  section,  we  shall  present  an  Object  Z  formulation  of  the  generic  integrity  model 
described  in  the  previous  section. 


3.1  Data  Types 

We  introduce  a  generic  type  describing  the  data.  At  the  moment,  we  treat  data  as  simply 
opaque  chunks. 

[Data] 


For  the  context  and  integrity  values,  we  introduce  top  level  classes  which  are  used 
in  the  specification  of  the  generic  structure  of  an  integrity  model.  Particular  integrity 
models  will  sub-class  these  in  order  to  accommodate  their  specific  needs,  e.g.  one  model 
may  require  discrete  values  (such  as  Biba  -  see  the  Appendices),  whilst  another  may  utilise 
continuous  values,  such  as  probability-based  models. 


ContextValue . 


Integrity LevelType  ::=  Integrity LevelProbType  \  IntegrityLevelBinaryType 


_ Integrity  Lev  el 


type  :  IntegrityLevelType 


We  also  define  a  class  to  represent  a  User,  including  a  user  rating  of  reputation.  Note 
that  this  will  be  dynamically  maintained  by  a  mechanism  currently  out  of  scope,  based  on 
e.g.  past  user  actions  and  the  consequences  of  those  actions. 

_ User _ 

reputation  :  j,  Context  Value 


The  event  types  and  context  dimensions  are  universal  to  all  models.  We  shall  populate 
them  here  with  specific  values  pertinent  to  our  SIATM  use  case  to  be  explored  later.  These 
two  definitions  will  simply  grow  as  more  models  and  instantiations  thereof  are  added  to 
our  universe. 

EventType  ::=  login  \  logout  \  copyToUSB  \  copyFromUSB  \  printDoc  \  transferDoc 
downgradeDoc  \  witnessedDoumgradeDoc 
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ContextDimension  ::=  source  Authentication  \  sourceAuthorisation  \  sourceReputation 
tamperResistance  \  reliability  \  time  \ 
completeness  \  storage  \  transport  \ 
generic 

For  future  reference  when  we  discuss  the  SIATM  in  a  later  section,  source  Authentication 
will  represent  the  degree  of  confidence  in  the  authentication  of  the  source  (perhaps  a  user) 
of  a  Data  Element.  It  will  be  affected  by  both  the  number  and  quality  of  authentication 
factors  utilised.  sourceReputation  will  represent  the  degree  of  confidence  in  the  source’s 
reputation,  based  upon  their  history  of  actions.  sourceAuthorisation  will  represent  the 
degree  of  confidence  that  the  authorisation  of  the  user’s  access  to  the  DataElenrent  was 
correctly  verified. 


3.2  Event 

The  Event  object  captures  the  time-stamped  type  of  an  event,  the  associated  user  and  the 
associated  context.  For  example,  for  ATM-related  operations,  the  context  values  in  the 
associated  context  vector  will  represent  features  specific  to  that  ATM  and  its  environment. 
Note  that  this  is  a  generic  sequence  of  undefined  length,  whereas  the  context  vectors 
associated  with  individual  Data  Elements  are  of  fixed  length  corresponding  to  a  specified 
Integrity  Model  (see  below).  Hence  the  Event  may  capture  more  information  than  is 
required  for  a  given  model  in  which  it  is  being  used. 

As  part  of  this  construct,  we  introduce  a  specific  Context  Vector  type  to  capture  a  set  of 
mappings  from  Context  Dimensions  to  Context  Values  (specifically,  the  relevant  sub-class 
of  Context  Value  pertinent  to  the  specific  model  in  question). 

ContextVector  ==  ContextDimension  -4*  j.  Context  Value 


_ Event _ 

type  :  Event  Type ; 
timestamp  :  N; 
user  :  User ; 

contextVector  :  ContextVector 


In  addition,  we  define  an  event  class  specifically  for  logging  of  events  in  an  audit  trail. 
In  our  ATM  specific  example  later,  this  will  be  used  in  the  ATM’s  internal  audit  log. 

_ LogEvent _ 

type  :  Event  Type ; 
timestamp  :  N; 
user  :  User 
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3.3  Integrity  Model 

The  integrity  model  specifies  the  relevant  Context  Dimensions  for  that  model,  the  relevant 
Context  Dimensions  for  a  given  Event  Type  within  the  model,  how  a  corresponding  context 
vector  is  to  be  updated  according  to  a  given  event,  and  how  the  integrity  of  a  tagged  Data 
Element  is  to  be  computed  from  the  Context  Vector  and  Initial  Integrity  of  that  Data 
Element. 

_ Integrity  Model _ 

unitVector  :  ContextVector 

relevantDimensions  :  F  ContextDimension] 
relevantEventDimensions  :  EventType  -H-  ContextDimension ; 
contextUpdate  :  (| Integrity  Lev  el  x  ContextVector  x  Event )  -+>■  ContextVector ; 
evaluatelntegrity  :  (^Integrity Level  x  ContextVector )  -A  \.IntegrityLevel 

dom  unitVector  =  relevantDimensions 
ran  relevantEventDimensions  C  relevantDimensions 
dom  contextUpdate  =  {l  :  IntegrityLevel ;  v  :  ContextVector ;  e  :  Event  \ 
dom  v  =  relevantDimensions  A 
e.type  £  dom  relevantEventDimensions  A 

ran ({e.type}  <  relevantEventDimensions )  =  dom  e. ContextVector} 
ran(dom  evaluatelntegrity)  =  {v  :  ContextVector  |  dom  i;  =  relevantDimensions} 


The  idea  is  that  each  Data  Element  (see  below)  will  carry  a  context  vector  recording 
its  context  for  each  of  the  relevant  context  dimensions  for  the  model.  However,  each  event 
is  only  required  to  carry  context  information  about  the  set  of  dimensions  relevant  to  that 
event  in  the  model.  This  is  for  reasons  of  economy  -  we  do  not  want  to  require  every  event 
to  be  forced  to  carry  information  unrelated  to  that  event’s  operation.  It  also  means  that 
we  may  more  easily  build  up  a  model  containing  multiple  events  event-by-event,  since  we 
will  not  need  to  retrofit  new  dimensions  to  the  schemas  representing  existing  events  when 
we  add  a  new  event  bringing  new  dimensions  to  the  model. 

On  that  last  point,  the  intent  is  that  the  relevant  dimensions  for  the  model  as  a  whole 
will  be  as  small  as  possible,  for  the  reasons  espoused  in  the  introduction  to  this  section. 
Hence,  typically  we  would  expect  the  relevant  context  dimensions  for  the  model  as  a  whole 
to  be  the  union  of  the  dimensions  relevant  to  each  of  the  event  types  associated  with  the 
model. 

Note  that  the  unitVector  is  a  Context  Vector  (covering  the  relevant  Context  Dimensions 
of  the  model)  which  is  used  to  initialise  the  Context  Vector  for  new  Data  Elements. 
Typically,  in  a  probabilistic  type  model,  it  is  the  vector  (1, 1, ... ,  1). 


3.4  File 

We  introduce  the  concept  of  a  File  as  a  sequence  of  Data  Elements,  and  it  is  the  Data 
Element  which  is  integrity-decorated.  The  granularity  at  which  this  breakdown  occurs  is 
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not  relevant  at  this  abstract  level.  We  note  though  that  when  reasoning  about  the  integrity 
of  a  file,  it  may  be  that  the  entire  file  needs  to  be  treated  itself  as  a  subject  of  integrity 
considerations.  Concepts  such  as  Completeness  and  Consistency  only  really  make  sense 
at  this  level,  rather  than  at  the  level  of  a  Data  Element.  The  introduction  of  the  relevant 
hierarchical  relations  amongst  Data  Elements  within  a  given  file  are  left  to  future  work. 

For  each  such  Data  Element,  an  initial  Context  Vector  is  assigned  on  creation.  This 
Context  Vector  may  then  be  updated,  using  the  function  specified  by  the  model,  as  each 
Event  occurs  to  the  data.  The  overall  Integrity  is  a  function  of  this  Context  Vector  and  an 
Initial  Integrity  value,  computed  using  the  function  specified  by  the  model.  As  described 
above,  these  operations  of  context  update  and  integrity  evaluation  are  model  specific. 

Note  that  the  model  referenced  by  the  Data  Element  is  a  sub-class  of  the  Integrity- 
Model.  We  shall  later  define  sub-classes  representing  specific  integrity  models.  We  also 
stress  here  that  though  we  referred  earlier  to  each  Data  Element  carrying  an  index  into 
a  list  of  integrity  models,  and  this  is  how  an  implementation  would  be  realised,  for  the 
purposes  of  the  abstract  model,  the  Data  Element  actually  includes  the  integrity  model 
itself. 


_ DataElement _ 

data  :  Data; 

context  :  Context  Vector ; 
initiallntegrity  :  Integrity  Level] 
integrity  :  {.Integrity Level] 
model  :  {. Integrity  Model ; 
contextUpdate  :  Event  -+>•  Context  Vector 

dom  context  =  model. relev antDimensions 

dom  contextUpdate  =  ran(dom  model. contextUpdate) 

V  e  :  dom  contextUpdate  •  contextUpdate(e)  =  model. contextUpdate(initialIntegrity,  context ,  e) 


_ getlntegrity _ 

integrity !  :  {.Integrity Level 

integrity !  =  model,  evaluatelntegrity  {initiallntegrity ,  context ) 


We  note  that  contextUpdate  does  not  actually  update  the  context  vector  of  the  Data 
Element.  It  simply  outputs  what  would  be  the  updated  context  vector  should  the  operation 
occur.  For  example,  in  the  Biba  Strict  Integrity  policy,  integrity  values  do  not  change. 
One  may  regard  the  model  as  stating  that  operations  are  forbidden  should  the  integrity 
value  change  were  the  operation  to  be  allowed.  See  Appendix  A  for  more  discussion. 

We  finally  define  the  file,  with  a  function  to  evaluate  the  integrity  of  a  specified  Data 
Element  in  a  given  file. 

_ File _ 

fileData  :  seq  DataElement 
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evaluatelntegrity  =  [  dl  :  ran fileData]  •  dl .getlntegrity 

_ get.Id _ 

filed  :  File 

file\  =  self 


4  Probabilistic  Model 

As  a  specific  example,  and  for  later  use,  we  define  here  an  instance  of  the  generic  model 
using  explicit  functions  for  contextUpdate  and  evaluatelntegrity,  where  context  values  are 
interpreted  probabilistically,  i.e.  the  Context  Value  represents  the  level  of  confidence 
appropriate  to  that  particular  Context  Dimension  for  the  Data  Element  in  question. 

To  that  end,  we  explicitly  define  the  appropriate  sub-classes  of  the  Context  Value  and 
IntegrityLevel  spaces. 

_ ContextValueProb _ 

Context  Value 

value  :  M 

value  >  0  A  value  <  1 


The  integrity  level  is  a  (non-negative)  real,  which  will  ultimately  be  defined  in  our 
example  model  as  the  length  of  the  context  vector,  once  we  have  assigned  a  metric  to  that 
context  space. 

_ Integrity  LevelProb _ 

IntegrityLevel 

value  :  M 

type  =  IntegrityLevelProbType 


We  need  a  utility  function  which  performs  component-wise  multiplication  of  context 
vectors.  Note  that  this  function  ignores  context  dimensions  not  in  common  between  the 
two  operands. 

multiply  :  ContextVector  x  Context  Vector  ->  Context  Vector 

V  a  :  ContextVector-,  b  :  ContextVector  • 

multiply  {a,  b)  =  {d  :  ContextDimension ;  v  :  ContextValueProb  \ 

3p,  q  :  ContextValueProb  •  (d,p)  €  a  A  ( d ,  q)  €  b  A  v. value  =  p. value  *  q. value} 

We  also  define  another  utility  function  which  sums  a  given  real- valued  function  over  a 
specified  set. 
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|=[g]  — 

set, Sum  :  {S  ->  M)  — >  M 

V/  :  dorn  set  Sum  • 

f  =  0  =>  setSum{f)  =  0  A 

/  ^  0  =^>  (V p  :  S;  q  :  M  |  (p,q)  €  f  •  setSum(f)  =  q  +  setSum(f  \  {(>,  q)})) 


We  can  then  define  our  model. 

Context  update,  because  of  the  simple  probabilistic  interpretation,  is  simply  (context 
dimension)  coordinate-wise  composition  of  (independent)  probabilities  by  multiplication. 
The  initial  context  vector  will  typically  start  as  the  sum  of  the  individual  orthogonal  unit 
basis  vectors  (i.e.  (1, 1, . . . ,  1)).  Then  our  update  mechanism  reflects  the  fact  that  we 
interpret  each  component  as  a  confidence  level  in  the  validity  of  that  particular  aspect  of 
context,  and  we  start  with  full  confidence,  for  argument’s  sake. 

Note  that  since  some  of  the  dimensions  relevant  to  the  model  are  not  relevant  to  a 
specific  event,  the  confidence  values  in  those  dimensions  are  not  affected  by  the  update. 
For  example,  the  context  value  corresponding  to  the  context  dimension  measuring  the 
confidence  in  the  authentication  of  a  user  may  be  largely  irrelevant  to  the  integrity  of  the 
file  in  an  operation  such  as  file  transfer  (with  no  opportunity  for  editing  of  the  data). 
However,  establishment  of  the  user’s  identity  is  clearly  critical  for  integrity  of  the  data  in 
other  use  cases,  as  well  as  of  course  for  other  security  factors,  such  as  confidentiality  of 
the  file. 

The  net  effect  of  this  simple  scheme  is  a  gradual  decay  in  confidence  (and  hence  in¬ 
tegrity).  We  shall  address  this  issue  later  when  we  discuss  fusion/amplification  (see  Ap¬ 
pendix  C). 

In  order  to  evaluate  the  integrity,  we  introduce  a  “metric”  g  on  the  space  of  context 
vectors.  This  will  measure  the  contribution  to  integrity  of  the  corresponding  context  di¬ 
mensions.  In  terms  of  the  probabilistic  interpretation  given  to  the  coordinates,  some  other 
measure  probably  makes  more  sense,  e.g.  the  simple  product  of  the  independent  context 
dimensions’  probabilities.  Hence  we  stress  that  this  particular  choice  of  a  ’’Euclidean- 
distance”  metric  is  just  an  example  -  specific  instantiations  of  the  framework  as  a  par¬ 
ticular  model  will  need  to  make  a  choice  of  function  which  is  of  value  in  their  particular 
scenario. 

Typically,  we  would  expect  the  matrix  g  to  be  diagonal,  but  in  general  it  will  be  a 
symmetric  non-negative  definite  matrix1,  which  allows  for  the  fact  that  our  coordinate 
choice  may  not  be  orthogonal,  i.e.  the  context  dimensions  may  not  be  independent. 
In  such  cases,  armed  with  the  “dot  product”  (inner  product)  of  vectors  defined  by  this 
metric,  one  may  then  go  through  a  standard  procedure  to  identify  an  orthogonal  basis 
(and  diagonalise  the  metric  in  those  new  coordinates). 

Essentially,  the  integrity  is  the  “length”  of  the  Context  Vector  v,  i.e.  vivj9ij)- 

The  use  of  this  “metric”  also  allows  us  to  weight  contributions  to  the  overall  integrity  from 

1We  can  force  it  to  be  positive  definite  by  simply,  in  the  first  place,  selecting  context  dimensions  which 
have  some  non-zero  impact  on  the  overall  integrity,  i.e.  choose  our  set  of  Relevant  Dimensions  for  the 
model  appropriately. 
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different  dimensions  according  to  their  relevance  in  that  particular  integrity  model,  i.e.  in 
the  context  in  which  integrity  is  being  evaluated. 

We  need  one  more  utility  function: 

sqrt  :  M  — >  M 

V  r  :  M  |  r  >  0  • 

3i:M|i>0»i*i  =  rA  sqrt(r)  =  i 

_ Probability  Model _ 

IntegrityModel 

unitVector  :  ContextDimension  ContextValueProb 
V  v  :  ran  unitVector  •  v. value  =  1 


g  :  ( relevantDimensions  x  relevantDimensions )  -A  M 

ran(dom(dom  contextUpdate))  C  ContextDimension  -A  ContextValueProb 
evaluatelntegrity  G 

IntegrityLevelProb  x  ( ContextDimension  -A  ContextValueProb)  -A  IntegrityLevelProb 
Vi  :  IntegrityLevelProb ;  v  :  ContextDimension  -A  ContextValueProb  \ 

(i,v)  G  dom  evaluatelntegrity  • 

(3  integrity  Contribution  :  (( relevantDimensions  x  relevantDimensions )  — >  M)  • 

(V  d,  e  :  relevantDimensions  • 

3p,  q  :  ContextValueProb  •  v{d)  =  p  A  v(e)  =  q  A 
(integrity Contribution^,  e)  =  g(d,  e)  *  p. value  *  q. value))  A 
(3j  :  IntegrityLevelProb  •  ( j  =  evaluatelntegrity (i,  v)  A 
j.  value  >  0  A 
j.  value  =  i.  value* 

sqrt  ( setSum  [ relevantDimensions  x  relevantDimensions ]  ( integrity  Contribution)) ) ) ) 
V  l  :  IntegrityLevelProb ;  v  :  ContextVector ;  e  :  Event  \  (l,  v,  e)  €  dom  contextUpdate  • 

3f  :  ContextVector  •  contextUpdate (l,  v,  e)  =  multiply(v,f)  A 
/  =  unitVector  0  e. ContextVector 


The  extension  of  the  context  vector  of  the  event  e  above  to  a  temporary  vector  /  is 
a  bit  of  a  subtlety.  We  need  to  ensure  that,  when  multiply  is  invoked  successively  on  the 
initial  context  vector  attached  to  a  piece  of  data,  that  we  maintain  context  values  for  each 
of  the  relevant  event  dimensions  in  the  model.  Since  the  event’s  context  vector  is  not 
required  to  have  entries  for  all  of  the  model’s  relevant  dimensions,  as  discussed  above,  we 
risk  losing  some  information.  Hence,  an  extension  vector  with  the  multiplicative  identity 
in  each  of  the  extended  components,  is  introduced. 


5  Application  to  SIATM  Use  Cases 

The  Secure  Information  ATM  (SIATM)  is  an  ATM-style  machine  currently  under  devel¬ 
opment.  The  underlying  concept  is  that  it  handles  transactions  involving  information, 
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as  opposed  to  currency.  It  will  be  deployed  as  the  gateway  for  information  transactions 
to/from  a  classified  network  or  networks,  and  provides  a  strong  audit  trail  linking  such 
transactions  to  (strongly)  identified  users  in  a  highly  accreditable  solution.  There  are  a 
number  of  possible  use  cases  which  may  be  supported.  Here  we  shall  focus  on  a  few  of 
the  simpler  ones,  including  USB  transfer  of  content  between  SIATMs,  printing  of  RFID- 
tagged  documents  and  downgrade  of  documents  between  classification  levels.  With  regards 
to  RFID-tagging  of  documents,  this  allows  for  the  automation  of  an  electronic  Classified 
Document  Register  (CDR),  adding  printed  documents  automatically  to  the  user’s  CDR, 
and  transferring  documents  between  users’  CDR’s  with  ease  via  a  suitable  transaction  at 
the  SIATM  involving  both  users.  The  focus  is  on  security,  though  combined  with  ease  of 
use. 


We  model  the  SIATM  at  an  idealised  abstract  level  as  containing  an  audit  log  of  critical 
operations  (modelled  as  a  sequence  of  events)  and  a  set  of  files.  It  may  have  at  most  one 
USB  memory  stick  inserted,  and  it  may  have  at  most  one  user  logged  in  at  any  given  time. 
In  addition,  we  model  a  CDR  documenting  ownership  of  the  set  of  files.  For  simplicity  of 
exposition,  it  simply  tracks  current  ownership  status  rather  than  a  history  of  files  owned 
for  each  user. 


We  shall  use  the  probabilistic  model  described  in  the  previous  section.  Note  that  these 
probabilities  are  to  be  interpreted  as  conditional  probabilities  given  the  assumption  that 
an  appropriate  signature  check  (a  trivial  integrity  guard)  on  the  file  passed  correctly,  i.e. 
we  focus  on  the  broader  aspects  of  integrity  which  are  the  focus  of  this  paper  and  assume 
simplistic  unauthorised  data  modification  is  prevented. 


As  a  general  point  in  this  analysis,  we  note  that  the  reliability  and  tamper  resistance 
of  the  SIATM  are  critical  -  any  malicious  software  in  the  device  can  clearly  modify  the 
underlying  file  data. 


Regarding  document  printing,  we  introduce  the  notion  of  hard  copies  of  documents  in 
the  system,  as  well  as  a  CDR.  Note  that  the  CDR  tracks  ownership  not  only  of  these  hard 
copies,  but  also  of  electronic  files  stored  on  USB  memory  sticks  (the  only  medium  we  have 
in  our  model). 


Obviously,  we  need  to  introduce  a  specific  Integrity  Model.  To  that  end,  we  utilise 
and  extend  the  previously  introduced  probabilistic  model.  The  SIATM-specific  tailoring 
of  the  generic  probabilistic  model  simply  involves  specification  of  the  exact  set  of  relevant 
dimensions  and  the  relevant  dimensions  for  each  event  type. 
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_ ModelOne _ 

Probability  Model 

relevantDimensions  =  {source  Authentication, 

source  Authorisation,  tamper  Resistance,  reliability,  time, 
completeness ,  storage,  transport,  sourceReputation} 
dom  relevantEventDimensions  =  {copyToJJSB ,  downgradeDoc,  print.Doc, 
transferDoc,  copyFromUSB} 
ran {{copyToUSB}  <1  relevantEventDimensions)  = 

{source  Authentication,  sourceAuthorisation,  tamper  Resistance, 
reliability,  time,  completeness ,  storage,  transport} 
r &n({downgradeDoc}  <  relevantEventDimensions )  = 

{source  Authentication,  sourceAuthorisation,  tamper  Resistance, 
reliability,  time,  completeness,  storage,  transport, 
sourceReputation} 

ran ({printDoc}  <1  relevantEventDimensions)  = 

{source  Authentication,  sourceAuthorisation,  tamper  Resistance, 
reliability,  time,  completeness,  storage,  transport} 
ran  ({transferDoc}  <1  relevantEventDimensions)  = 

{source  Authentication,  sourceAuthorisation,  tamper  Resistance, 

reliability,  time,  completeness, 

sourceReputation} 

ran {{witnessedDowngradeDoc}  <\  relevantEventDimensions)  = 

{source  Authentication,  sourceAuthorisation,  tamper  Resistance, 
reliability,  time,  completeness ,  storage,  transport, 
sourceReputation} 

ran  ({copyFromUSB}  <1  relevantEventDimensions)  = 

{source  Authentication,  sourceAuthorisation,  tamper  Resistance, 
reliability,  time,  completeness ,  storage,  transport} 


The  USB  stick  is  introduced.  It  is  simply  a  container  for  files. 

^USB _ 


files  :  F  File 

-  readFile _ 

A  (files) 
file ?  :  File 

files'  =  files  U  {file*?} 


-  writeFile  _ 
file!  :  files 


The  ATM  is  a  container  of  files  (with  designated  access  by  users)  and  a  log,  and  may 
have  a  user  logged  in  and/or  a  USB  memory  stick  inserted.  Various  hard-coded  parameters 
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indicate  its  reliability  in  various  context  dimensions.  For  example,  userAuthenticationVa- 
lue  indicates  the  probability  for  the  system  of  correct  authentication  of  a  user  using  a 
biometric  factor  in  addition  to  an  RFID  card  swipe.  For  simplicity  in  this  example  model, 
this  is  assumed  to  be  constant  across  all  users. 

ATM _ 

files  :  F  File ; 

log  :  seq  Log  Event] 

user  :  F  User ; 

time  ATM  :  N; 

usb  :  F  USB; 

allowedUsers  :  F  User ; 

fileAccess  :  File  User; 

reliability  Value  :  ContextValueProb ; 

tamper ResistanceValue  :  ContextValueProb; 

userldentificationValue  :  ContextValueProb; 

[user  does  simple  RFID  swipe] 
userAuthenticationValue  :  ContextValueProb; 

[biometric  authentication] 

userAuthorisationValue  :  ContextValueProb; 
storageReliability Value  :  ContextValueProb 

{fiuser)  <  1 
user  C  allowedUsers 
(fiusb)  <  1 


_ logEvent _ 

A  (log) 

e?  :  LogEvent 
log'  =  log  ^  (el) 


_ tick _ 

A  (timeATM) 

time  ATM’  =  timeATM  +  1 


_ login _ 

A (user) 
user 1  :  User; 
e!  :  LogEvent 

user  =  0 

userl  e  allowedUsers 
e!  -type  =  login 

e\. timestamp  =  timeATM  A  el. user  =  userl 
user ’  =  {userl} 
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login  ATM  =  login  ||  log  Event 

_ insertUSB _ 

A (usb) 
usb ?  :  USB 

user  /  0 
usb  =  0 
usb'  =  {usb?} 


_ remove  USB _ 

A (usb) 

usb  /  0  A  usb'  =  0 
user  /  0 
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writeFile 


file ?  :  files; 
file\  :  File; 
user?  :  User; 
eventType ?  :  EventType; 
el  :  LogEvent 

user  =  {user?} 
file?  i->-  user?  €  fileAccess 
el. type  =  eventType?  A  el. timestamp  =  timeATM 
el. user  €  user 
3  m  :  Event  • 

dom  filel.fileData  =  dom  file? .fileData  A 
(V  n  :  dom  filel.fileData  • 

(filel .fileData(n)) . data  =  (file?.  fileData(n)).  data  A 
(filel.fileData(n)). context  =  (file? .fileData(n)) .contextUpdate(m)  A 
(filel. fileData(n)).initialIntegrity  =  (file? .fileData(n)) .initiallntegrity  A 
(filel. fileData(n)) .model  =  (file?. fileData(n)). model)  A 
m.type  =  eventType?  A 

m. timestamp  =  timeATM  A  m.user  £  user  A 
m.  context  Vector  = 

{source Authentication  i-A  userldentificationValue , 

[no  fingerprint  check,  so  RFID  user  id  confidence  only] 

source  Authorisation  t-A  userAuthorisationValue, 

tamperResistance  i-A  tamper  Resistance  Value, 

reliability  >-)•  reliability  Value, 

time  i-A  reliability  Value, 

completeness  i-A  reliability  Value, 

storage  i-A  storageReliability  Value, 

transport  >-)•  reliability  Value} 

[The  ATM  version  of  each  method  logs  the  event  to  the  SI  ATM’s  log] 

writeFile  ATM  =  writeFile  ||  log  Event 


[ writeFile  is  a  utility  method  utilised] 
[by  a  few  high  level  use  cases,] 
[e.g.  for  printing  and  also  transferring  to  USB.] 
[It  outputs  a  copy  of  the  file  with  an  updated] 
[context  vector,  as  well  as  a  log  entry  for  the  event] 
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_ readFile _ 

[Similar  utility  function.  Updates  ATM’s  file  set] 
[with  copy  of  given  file,  after  updating  context  vector.] 

A  (files,  file  Access) 
file ?  :  File ; 
user?  :  User ; 
eventType?  :  EventType ; 
e!  :  LogEvent 

user  =  {user?} 

e ! . type  =  eventType?  A  e\. timestamp  =  timeATM 
e\.user  E  user 
3  m  :  Event ;  /  :  File  • 

dom  f.fileData  =  dom  file? .fileData  A 
(V  n  :  dom  /  .fileData  • 

(/ .fileData(n)) .data  =  (file?  .fileData(n))  .data  A 
(/ .fileData (n)). context  =  (file? .fileData(n)) .contextUpdate(m)  A 
(/ .fileData(n)) .initiallntegrity  =  (file? .fileData(n)) .initiallntegrity  A 
(/ .fileData(n)). model  =  (file? .fileData(n)) .model)  A 
file  Access'  =  file  Access  U  {/  i — >•  user?}  A 
files'  =  files  U  {/}  A 
m.type  =  eventType?  A 

m. timestamp  =  timeATM  A  m.user  G  user  A 
m.  context  Vector  = 

{sourceAuthentication  i-A  userldentificationValue, 

[no  fingerprint  check] 

source  Authorisation  >-)•  userAuthorisationValue , 

tamperResistance  i-A  tamper  Resistance  Value , 

reliability  reliability  Value, 

time  i-A  reliability  Value, 

completeness  i-A  reliability  Value, 

storage  i— >•  storageReliability  Value, 

transport  i-A  reliability  Value} 

readFileATM  =  readFile  ||  logEvent 
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_ transferDoc _ 

[CDR  transfer  functionality.] 

[Acts  on  what  will  be  printed  documents  (not  files  in  ATM  fileset).] 
[Updates  context  vector  of  printed  document.] 

[Idea  is  that  this  metadata  will  be  attached  via  an  electronic  record  or  in  RFID.] 

A  (files) 
file ?  :  File ; 
filel  :  File ; 
source?  :  User ; 
destination ?  :  User ; 
e!  :  LogEvent 

user  =  {source?} 
destination?  £  allowedUsers 

el. type  =  transferDoc  A  e\. timestamp  =  time  ATM 
e\.user  £  riser 
3  m  :  Event  • 

dom  filel. fileData  =  dom file? .fileData  A 
(V  n  :  dom  filel. fileData  • 

(filel.  fileData(n)).  data  =  (file? .fileData(n)). data  A 
(filel. fileData(n)). context  =  (file? .fileData(n)) .contextUpdate(m)  A 
(filel. fileData(n)) .initiallntegrity  =  (file?  .fileData(n))  .initiallntegrity  A 
(filel. fileData(n)). model  =  (file?. fileData(n)). model)  A 
m.type  =  transferDoc  A 

m.  timestamp  =  time  ATM  A  m.user  G  user  A 
m.  context  Vector  = 

{source Authentication  eA  userAuthenticationValue , 
source  Authorisation  eA  userAuthorisationValue, 
tamperResistance  i-A  tamper  Resistance  Value , 

[Electronic  storage  of  file  history] 

reliability  >-)•  reliability  Value, 
time  eA  reliability  Value, 
completeness  eA  source? .reputation, 

[Complete  set  of  pages  depends  on  user  trustworthiness] 

sourceReputation  i-A  source? .reputation} 

transfer  Doc  ATM  =  transferDoc  ||  logEvent 
copyToUSBATM  =  [u?  :  usb]  •  ([  eventType?  :  EventType \ 
eventType?  =  copyToUSB]  AwriteFileATM)  ||  u?.readFile 
copy FromUSB ATM  =  [u?  :  usb  \  u?  £  us6]  •  u? .writeFile  ||  ([ eventType ?  :  Event.Type\ 
eventType?  =  copyFromUSB ]  AreadFileATM) 

printDocATM  =  [eventType?  :  EventType\ 
eventType?  =  printDoc]  AwriteFileATM 
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_ doumgradeDocument _ 

[This  and  next  op  are  front  ends  for  downgrading] 
[This  one  with  single  user  and  next  op  is  witnessed] 

doumgradeTypel  :  EventType; 
sourceAuthenticationValuel  :  ContextValueProb 

downgradeTypel  =  doumgradeDoc 

[User  authenticates  operation  via  fingerprint] 

sourceAuthenticationValuel  =  userAuthenticationValue 


_ witnessedDowngradeDocument _ 

downgradeType\  :  EventType; 
sourceAuthenticationValuel  :  ContextValueProb 

downgradeTypel  =  witnessedDoumgradeDoc 

[Both  users  authenticated  operation  via  fingerprints] 

sourceAuthenticationValuel  =  userAuthenticationValue  *  userAuthenticationValue 
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_ downgradeDocumentCommon _ 

A  (files) 

downgradeType!  :  Event  Type ; 

source  AuthenticationValue!  :  ContextValueProb; 

file ?  :  File ; 

[User  picks  data  elements  to  redact] 

user  Selection!  :  FN; 
e!  :  LogEvent 

userSelection ?  Cl.,  fffile!  .fileData 
user  /  0 

e!  -type  =  downgradeType ?  A  e\. timestamp  =  time  ATM 
e\.user  €  riser 

3  u  :  user  •  (file!,  u )  6  fileAccess  A 

(3/  :  Fite;  m  :  Event ;  filteredData  :  seq  DataElement  \ 
filteredData  =  userSelection!  }  file! .fileData  • 
dom/. fileData  =  dom  filteredData  A 
(V  n  :  dom  /  .fileData  • 

(/ .fileData(n)) .data  =  (filteredData(n)) .data  A 
(/ .fileData(n)). context  =  ( filteredData(n)) .contextUpdate(m )  A 
(/ .fileData(n)).initialIntegrity  =  (filteredData(n)).initialIntegrity  A 
(/ .fileData(n)). model  =  (filteredData(n)) .model)  A 
m.type  =  downgradeType!  A 
m. timestamp  =  timeATM  A  m.user  £  user  A 
files'  =  files  U  {/}  A 
m.  context  Vector  = 

{source Authentication  >-)•  sourceAuthenticationValue! , 

sourceAuthorisation  i— )•  userAuthorisationValue, 

tamperResistance  eA  tamper Resistance  Value, 

reliability  i-A  reliability  Value, 

time  i-A  reliability  Value, 

completeness  i-A  reliability  Value, 

storage  i-A  storageReliability  Value, 

transport  i-A  reliability  Value, 

sourceReputation  i-A  u. reputation}) 

downgradeDocATM  =  downgradeDocument  ||  downgradeDocumentCommon  ||  logEvent 

witnessedDowngradeDocATM  =  witnessedDowngradeDocument  || 
downgradeDocumentCommon  ||  logEvent 
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_ logout _ 

A (user) 
el  :  LogEvent 

usb  =  0 

user  /  0A  user'  =  0 

el.  type  =  logout  A  el.  timestamp  =  time  ATM 
el. user  £  user 

logout  ATM  =  logout  ||  logEvent 


CDR _ 

possession  :  File  -+>•  User 


_ add _ 

file ?  :  File ; 
user?  :  User 

file ?  0  dom  possession 

possession'  =  possession  U  {file?  i-A  user?} 


_ transfer _ 

file?  :  File ; 

source?,  destination?  :  User 

file?  i-A  source?  £  possession 

possession'  =  possession  0  {,/i/e?  >->•  destination?} 


_ remove _ 

file?  :  File 

file?  £  dom  possession 
possession'  =  {file?}  ^  possession 
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_ System _ 

atms  :  F  ATM ; 
usbs  :  F  USB; 
cdr  :  CDR; 
model  :  ModelOne ; 
printedDocs  :  F  File 
A 

files  :  F  File 

files  =  printedDocs  U  U{a  :  atms  •  a. files}  U  U{w  :  usbs  •  u. files} 
dom  cdr  .possession  =  printedDocs  U  U{w  :  usbs  •  u. files} 

V/  :  files  •Vo?:  ran  f.fileData  •  d. model  =  model 

tick  =  A  a  :  atms  •  a.  tick 

loginATM  =  [  atm ?  :  aims]  •  atm! .login ATM 

insertUSBATM  =  [atml  :  atms]  •  [ usbl  :  usbs]  A  atml  .insert  USB 

copyToUSBATM  =  [atml  :  atms]  •  atml.  copy  To  USB  ATM  A  cdr. add 

copyFromUSBATM  =  [atml  :  atms]  •  atml  .copy  FromU SB  ATM 

printDocATM  =  [atml  :  atms]  •  atml .printDoc ATM  A  cdr. add  || 

[A  (printedDocs)  file!  :  File  \  printedDocs'  =  printedDocs  U  {file!}] 
removeUSBATM  =  [atm!  :  atms]  •  atm! .removeUSB 
logoutATM  =  [atm!  :  atms]  •  atm!  .log  out  ATM 

transfer  Doc  ATM  =  [  atm 1  :  atms ;  /?  :  printedDocs]  •  fl.getld  || 
atm! . transfer  Doc  ATM  A  cdr  .transfer 

downgradeDocATM  =  [atm!  :  atms]  •  atml. downgradeDoc ATM 
witnessedDowngradeDocATM  =  [atm!  :  atms]  •  atm! .witnessedDowngradeDocATM 
evaluatelntegrity  =  [file!  -.files]  •  file!  .evaluatelntegrity 


6  Future  Work 

There  are  a  number  of  open  questions  which  need  to  be  explored  in  ongoing  work.  For 
example,  the  specific  operation  of  data  merging  needs  to  be  considered,  beyond  the  ini¬ 
tial  discussion  currently  in  Appendix  C.  This  is  the  amplification  mechanism  (a  critical 
requirement  of  our  model),  and  it  can  serve  to  increase  integrity  if  independent  sources 
attest  to  the  same  data  value(s).  In  general,  most  operations  serve  to  reduce  context  di¬ 
mensions’  confidence  values,  but  the  data  merging  example  is  (one  of)  the  exception(s)  in 
which  confidence  in  integrity  may  be  increased.  Also,  one  must  handle  the  management 
of  amplification  of  integrity  via  merging  data  from  partially  independent  sources. 

Similarly,  integrity  concepts  such  as  Completeness  and  Consistency,  which  may  make 
sense  only  across  a  file  or  set  of  hies,  are  not  yet  considered. 

One  other  factor  which  must  be  further  expanded  upon  is  the  change  in  integrity  (or 
required  integrity)  of  the  data  due  to  change  of  the  context /environment,  e.g.  at  the 
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simplest  level  the  data  is  no  longer  correct  because  the  situation  has  changed.  The  issue 
of  required/sufficient  integrity  depending  on  context  has  many  critical  implications  for 
Military  systems.  As  a  simple  and  obvious  example,  a  targeting  process  may  report  a 
geographic  location  within  a  defined  error  range.  The  resulting  course  of  action  or  method 
of  operation  by  a  Commander  could  be  very  different  if  the  location  was  in  a  very  sparsely 
populated  desert,  as  opposed  to  a  densely  populated  urban  environment.  Context  of  the 
integrity  measurement  for  the  purposes  of  deciding  whether  sufficient  integrity  exists  given 
the  circumstances  of  the  moment  is  essential. 

One  approach  to  these  issues  is  to  take  this  environmental  context  into  account  as  an 
input  into  evaluatelntegrity.  Another  approach  is  to  address  the  change  in  environment 
by  use  of  a  different  integrity  model  index  (which  leads  then  to  use,  in  particular,  of  a 
different  evaluatelntegrity  function)  in  that  situation,  with  the  appropriate  constraints  on 
the  consistency  of  the  set  of  relevant  context  dimensions  for  each  model  in  order  to  make 
the  interpretation  consistent.  This  forms  the  basis  of  ongoing  work. 

The  exploration  in  Appendix  A  of  how  to  represent  the  Biba  model  within  our  frame¬ 
work  raises  the  question  of  how  we  extend  the  model  to  accommodate  security  policy 
specification. 

As  discussed  in  Section  2.1,  further  research  is  required  in  order  to  explore  various 
alternative  mechanisms  for  handling  data  transition  between  models  in  a  natural  way. 

Finally,  we  need  to  take  the  formal  model  further  insofar  as  we  need  to  explicitly  claim 
and  prove  appropriate  security  properties. 

As  well  as  to  anonymous  referees,  the  authors  are  indebted  to  the  following  individuals 
for  discussions,  suggestions  and  advice:  Angela  Billard,  Michael  Chase,  Aaron  Frishling, 
Damian  Marriott,  Alex  Murray,  Tristan  Newby  and  Chris  North. 
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Appendix  A  Biba 


As  another  example  of  a  specific  model,  we  define  here  an  instance  of  the  generic  model 
which  implements  the  Biba  model.  We  shall  consider  Integrity  Values  of  only  Low  and 
High.  For  simplicity,  we  shall  take  Context  Values  also  in  this  same  space.  Using  a 
single  Context  Dimension,  the  evaluatelntegrity  mechanism  is  then  no  more  than  a  simple 
identity  map  from  the  (unique)  Context  Value  in  the  Context  Vector  across  to  the  Integrity 
Level  space. 


Binary  ::=  Low  \  High 


_ ContextValueBinary 

Context  Value 

value  :  Binary 


_ Integrity  LevelBinary 

Integrity  Lev  el 


value  :  Binary 

type  =  IntegrityLevelBinaryType 


In  the  specification  of  the  model,  evaluatelntegrity  is  defined  as  an  identity  map  when 
the  initial  integrity  is  High.  Otherwise  the  integrity,  starting  Low,  remains  Low. 


contextUpdate  must  take  the  context  vector  of  the  object  under  consideration  and 
produce  a  context  vector  whose  (again  single  remember,  as  this  is  one  dimensional)  context 
value  is  the  minimum  of  the  context  value  of  the  object  under  consideration  and  that  of 
the  event  (we  have  not  defined  an  ordering  on  the  Context  Value  space,  and  so  we  need 
to  define  it  as  a  simple  truth  table). 
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_ BibaModel _ 

Integrity  Model 

unitVector  :  ContextDimension  -+>•  ContextValueBinary 

V  v  :  ran  unitVector  •  v. value  =  High 

ran(dom(dom  contextUpdate))  C  ContextDimension  -+>•  ContextValueBinary 
evaluatelntegrity  6 

IntegrityLevelBinary  x  ( ContextDimension  -4*  ContextValueBinary)  -+>•  IntegrityLevelBinary 
relevantDimensions  =  {generic} 

V  i  :  IntegrityLevelBinary ; 

v  :  ContextDimension  -+>•  ContextValueBinary  \  (i,v)  €  dom  evaluatelntegrity  • 

(3 p  :  ContextValueBinary ;  j  :  IntegrityLevelBinary  • 
v(generic)  =  p  A  evaluatelntegrity (i,  v)  =  j  A 
(i. value  =  Low  =>•  j. value  =  Low )  A 
(i.  value  =  High  =>•  j.  value  =  p.  value)) 

V  l  :  IntegrityLevelBinary ;  v  :  ContextVector\  e  :  Event  \  (l,  v,  e)  €  dom  contextUpdate  • 

q  :  ContextValueBinary  •  e.  context  Vector  (generic)  =  p  A  q. value  =  Lou>  A 
p. value  =  High  =>  contextUpdate(l ,  u,  e)  =  {(generic,  v(generic))}  A 
p. value  =  Low  =>  contextUpdate(l,  v,  e)  =  {(generic,  q)} 


Although  we  will  not  go  into  full  details  here,  how  this  would  be  applied  would  be 
that  there  would  be  context  vectors  attached  to  subjects  (users/processes)  as  well  as  data 
objects  in  the  system.  An  operation  which  results  in  information  flow  to  a  subject/object 
(e.g.  user  when  user  reads  data  or  object  when  user  writes  data)  may  result  in  the  context 
vector  of  that  flow  target  being  updated. 

An  overarching  security  policy  might  say  e.g.  any  operation  that  results  in  the  integrity 
of  the  target  being  reduced  is  disallowed  (Biba  Strict  Integrity  Policy).  This  amounts  to 
no  write  up  or  read  down.  We  have  not  discussed  security  policy  in  this  paper.  It  exists  at 
the  next  level  up  -  now  we  have  the  capability  to  evaluate  integrity,  our  policy  will  specify, 
as  a  consequence,  which  actions  are  allowed.  This  is  left  to  future  work. 
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Appendix  B  Data  Export 

Transition  of  a  DataElement  from  one  model  to  another  is  accomplished  by  the  following 
operation,  which  simply  sets  the  initial  integrity  level  of  the  new  DataElement  to  the 
current  integrity  of  the  input  DataElement,  and  initialises  its  context  vector  appropriately 
(unit  value  in  the  relevant  dimensions  of  the  new  model).  The  raw  data  value  is,  of  course, 
copied  across  unchanged. 

exportDataElement  :  DataElement  x  \.IntegrityModel  — >  DataElement 

dom  exportDataElement  =  {d  :  DataElement ;  m  :  ^Integrity  Model  \ 

V k  :  ran ((d.model).evaluatelntegrity); 
l  :  ra,n(m.evaluatelntegrity)  •  k.type  =  l.type} 

V  d  :  DataElement ;  m  :  ^Integrity Model  • 

3  e  :  DataElement  •  e.data  =  d.data  A 

e. context  =  m.unitVector  A 
e.initiallntegrity  =  d. integrity  A 
e. model  =  m  A 
exportDataElement (d,  m)  =  e 

Note:  the  domain  of  the  exportDataElement  method  is  constrained  so  that  it  may  only 
map  between  models  with  compatible  Integrity  Level  spaces  (or  else  we  would  require  an 
additional  layer  of  transition). 
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Appendix  C  Vector  Space  Structure  and 
Fusion  /  Amplification 

We  shall  consider  the  definition  of  addition  and  scalar  multiplication  operations  on  the 
space  of  context  vectors  in  the  probabilistic  model  in  order  to  make  it  into  a  vector 
space. 

Clearly,  since  we  are  trying  to  interpret  the  coordinates  in  the  n-tuples  as  probabilities, 
we  cannot  naively  add  coordinate- wise  or  we  quickly  go  out  of  the  range  [0, 1]. 

As  a  simple  example  of  how  amplification  might  be  achieved  within  our  framework,  we 
define  the  addition  of  vectors  to  correspond  to  the  simple  combination  of  the  probabilities 
from  two  independent  sources  of  the  same  data.  Consider  a  trivial  example  of  two  sensors 
reporting  on  the  outcome  of  a  (fair  and  unbiased)  coin  toss.  One  reports  accurately  with 
probability  c  and  the  other  with  probability  d.  The  “sum”  of  coordinates  c  and  d,  i.e. 
the  probability  that  say  the  result  is  heads  given  that  both  sensors  report  heads,  would 
be  cd/(  1  —  c  —  d  +  2 cd). 

Extending  this  coordinate  definition  for  the  whole  vector,  for  Context  Vectors  c  and  d 
and  a  scalar  A,  we  may  define 

(c  +  d)i  =  Ci<k/(  1  -  a  -  di  +  2 a<k) 

(A  • c)i  =  c4a/((1  —  c*)A  +  c*A) 

This  effectively  makes  the  amplification  operation  in  the  data  space,  for  independent 
sources,  homomorphic  with  vector  addition  in  the  context  space.  That  is,  the  amplification 
a  of  independently  sourced  Data  Elements  d\  and  cfo  is  such  that  c(a(d\,  da))  =  c(d\ )  + 
c(da),  where  the  function  c  returns  the  context  vector  of  the  data  item.  (We  assume  for 
simplicity  now  that  the  underlying  data  is  actually  the  same  between  the  two  sources. 
Cases  where  there  is  overlap  or  even  contradictions  are  to  be  considered  once  we  have 
made  sense  of  this  simplest  possible  case).  Note  that  this  resultant  piece  of  data  a(d\ ,  da) 
then  decays  by  context  update  as  operations  are  subsequently  performed  on  it,  etc. 

In  practise,  for  not  fully  independent  sources,  the  amplification  function  (arrived  at  by 
Dempster-Shafer  or  other  mechanism)  will  be  such  that  c(a(di,  da))i  is  less  (coordinate- 
wise)  than  this  (upper)  bound.  In  fact,  the  discrepancy  between  the  vectors  c(a(di,  da)) 
and  c(d\)  +  c(da)  will  give  some  measure  of  the  degree  of  dependence  of  the  sources,  e.g. 

their  independence  is  correlated  with  ( c(di)+ ’c(dl)\- i UAH-' c Ok) )  ’  *‘e'  making  use  °f  the  scalar 
product  in  the  vector  space. 

We  may  check  that  these  definitions  of  vector  space  addition  and  scalar  multiplication 
satisfy  the  appropriate  relations  to  be  a  vector  space. 

However,  a  (trivial)  observation  is  that  we  at  best  have  a  semi-vector  space  [Liu  2010] 
(there  is  no  additive  inverse  of  any  element). 
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